Biggs' Apps

June 1, 2018

Part 1

Why why why why why didn't the Google team make RecyclerViews work with Cursors (and consequently databases)? They did it with ListViews, the "old" UI that RecyclerView is supposed to replace.

Answer: because it was difficult. And to be honest, the programmers at Google are much better at being fashionable hipsters than at making good code. (Rant on Google's Android UI team is brewing--stay tuned!)

The Problem

As I see it, the problem comes down to two things:

1. The need for RecyclerViews to mimic list data structures.
2. The fact that Cursors are not Lists.

Oh boy, is this obvious.

Since Cursors behave similarly to lists, one would naturally think that there'd be no problem. But think about it: Cursors by their very nature don't like being cached. They aren't designed for fast access. RecyclerViews with their forced ViewHolder model is all about speeeeeed! Herein lies the rub.

All this is of course just conjecture on my part. I haven't done any code-diving to check my hypothesis. But it seems to me that it's the speed issue that the Google Android UI developers couldn't crack. So they gave up. And thus we're left with a user-interface that's less than ideal.

By the way, has anyone out there actually had the opportunity to ask anyone at Google why they didn't supply Cursor support for RecyclerViews? To my knowledge they have been strangely quiet on this very important issue.

Of course, if our data were always in list form (like Lists, ArrayLists, etc.) there would be no problem. But damn, that built-in SQLite database is very nice. It's fast, easy, flexible, and probably the most robust Android library I've used. Sure, the SQL language is cringeworthily archaic, but the alternative is even worse: making a new database language, giving a bunch of old-timers heart-attacks.

Also, updating data via web services can be very ugly using Lists. Cursors tend to work much better. I haven't done much with this, but it's something to ponder.

Notable Attemps

I've seen a few tries at solving the problem. You can find several RecyclerView Cursor Adapters on GitHub and various blogs around the web. Most are like this that degrade RecyclerViews to ListViews. All the nice UI stuff no longer works with this system, so you might as well just stick with a ListView. You can recognize these because they always include a "swap" method somewhere.

This guy got the RecyclerViews to work well with all the UI bells and whistles, but is an unacceptably computationally expensive. He keeps a seperate list for the RecyclerAdapter to use and constantly compares it to a Cursor to detect changes. Yep, it's just what you imagine: O(n^2)!

And some are simply so bad they just crash when actually used outside of their demo. Too bad the internet is filled with craptastic code like this. But it makes me laugh at the guys who slap programs together by cutting and pasting from various websites. Serves you suckers right! (Of course the joke's on me as I frequently have to fix those slapped-together programs, SIGH!)

More coming soon...